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Hardcopy Extraction Considerations for Vector Product 

Format (VPF) Products 

Kimberley H. Berger 

Defense Mapping Agency Aerospace Center 
Digital Products Department 
3200 South Second Street 
St. Louis, MO 63118-3399 

Introduction 

Vector Product Format (VPF) is a standard format developed 
by the Defense Mapping Agency (DMA) intended to be used for 
organizing large geographic databases. Part of what distinguishes 
products in this format from those traditionally produced by DMA is 
the fact that they have both attribution and the potential for full 
topology. This format allows the products to be used directly in 
Geographic Information Systems (GIS), thus allowing users much 
greater analytical capability. 

Several VPF products have already been defined (see Table-1), 
though not all have been fully developed. In developing each VPF 
product, a Military Specification is written which defines, among 
other things, the themes or coverages into which the data are 
divided, the features to be found in each coverage, capture/portrayal 
criteria for particular features, attributes for features, and valid 
attribute values. Although the product specifications define the basic 
product structure, there are many collection and production issues 
which are not addressed. 

Table-1 VPF Products 

Product Scale/Source 

Digital Chart of the World (DCW) 1:1,000,000 (ONCs) 

Vector Smart Map (VMapO) 1:1,000,000 (DCW reformatted) 

Vector Smart Map (VMapl) 1:250,000 (JOGs) or 

1:200,000 (ATCs) 

Vector Smart Map (VMap2) 1:50,000 or 1:100,000 (TLMs) - 

Urban Vector Smart Map (UVMap) Variable Scale - High 

Resolution (City Graphics) 

Digital Nautical Chart (DNC) Variable Scale (Harbor, 

Approach, Coastal and General) 

Vector Product Interim Terrain 

Data (VITD) 1:50,000 or 1:100,000 (ITD) 
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One important issue is that of extraction source. Although the 
capability exists for image exploitation, the VPF product databases 
presently in production are being populated with data taken from 
existing hardcopy map source of appropriate scale. The use of 
cartographic source in building VPF product databases introduces 
issues concerning data consistency and source interpretation which 
should be considered before beginning full-scale production. This 
paper will address these and other more general data collection and 
organizational concerns for VPF products. Particular attention will be 
given to VMap Level 1 (VMapl) production experiences at the DMA 
Aerospace Center in St. Louis, Missouri, 


Map Series 

If cartographic source will be used it is preferable, for the sake 
of consistency, that one map series be chosen to populate the 
product’s database. Map series’ vary greatly in both 
collection/portrayal criteria for features and in classes of features 
portrayed. 

In producing VMapl, DMA’s Joint Operation Graphics (JOG) 
series' have been used as source. There are, however, several 
different types of JOGs: Ground (JOG-G), Air (JOG-A), Combined (JOG- 
C), and Radar (JOG-R); each having slightly different JOG 
Specifications. For example, roads on a JOG-A would specify the 
surface type and weatherability but not status (primary or 
secondary), whereas roads on a JOG-R may specify only status. For 
this reason, if a map series is further categorized, it is preferable to 
choose one type as the primary source. 

Just as the VPF product is defined by a product specification, 
the map series chosen for the extraction source also has a 
specification. In order to code and attribute features correctly, 
personnel populating the VPF product database must understand the 
specifications of the source. Understanding the portrayal criteria for 
the map features will help the production operator correctly 
attribute the VPF product’s features. Similarly, knowing the 
exceptions to these portrayal rules will be of benefit. 

An example of how this background knowledge aided in 
making attribution decisions for VMapl is in the case of bridges. In 
order to be portrayed on a JOG, a bridge must be at least 150 meters 
in length. The minimum size bridge symbol, however, represents 
380 meters. Any bridge between 150 and 380 meters long, 
therefore, is given a 380 meter standardized symbol length. Any 
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bridge greater than 380 meters long is symbolized to scale. The 
Draft Military Specification for VMapl defines two types of bridge 
features: line bridges being greater than or equal to 125 meters in 
length and point bridges being less than 125 meters in length. 
Because on the JOG source all collected bridges are at least 150 
meters long, there should never be a JOG bridge short enough to be 
collected as a VMapl point bridge. If operator measurement 
indicates the standardized 380 meter length (allowing a buffer for 
scanning or digitizing error), the length for the VMapl bridge is 
attributed as "unknown" as the operator has no way of knowing its 
actual length. Without understanding the JOG Specifications the 
operator would have coded the bridge with a length of 380 meters. 
Having this background information aided in making the correct 
attribution decision. 

Once a map series has been decided upon, it should be kept in 
mind that there may be several editions of the specifications, each 
possibly having its own unique set of features and capture criteria 
and symbology used for those features. Many of the source maps 
may have been compiled or revised under different editions of the 
source product specifications. Figure-1, for instance, shows the 
difference in airport portrayal from the 1968 and 1976 JOG-A 
Specifications. JOGs produced after 1976 no longer depict runways 
within the circle to scale. Instead they have a standard symbol with 
only the runway orientation varying. The runway length, to the 
nearest hundred feet, and surface type are given following the 
airport's name. Even if the changes from one edition to another are 
small, identifying them in advance could help to avoid confusion 
later. 


196 8 


1976 


EDNA 

755 


EDNA/24/S 

755 




Figure-1 


Source Media 
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Once the decision has been made to use existing hardcopy maps 
as source, the source media preference and availability must be 
determined. The preferred media will depend on the methods of 
data input and feature recognition. Primary source materials may 
come in the following forms: film positives or negatives, film feature 
separates, film color composites, and/or paper maps. 

Regardless of input method, paper source is regarded by DMA 
to be the least desirable media because it is highly subject to 
expansion, shrinkage, and warping. Feature recognition from 
scanned paper maps has not proven to be effective and efficient due 
to color variations and feature density. If the source will be scanned, 
film feature separates or film color composites are preferred. 

Although training for automatic feature recognition is possible using 
color composites, DMA prefers to use feature separates instead as 
they allow for easier, more successful recognition training. If 
scanning resources are constrained and interactive line following 
algorithms will be used, color composites may be preferred. 


Planning 

Several details must be addressed prior to beginning data 
collection. Certain historical information, or metadata, about the 
source such as datum, ellipsoid, and projection should be identified in 
order to support any required coordinate transformations. 

Appropriate source materials (eg. film positives, film separates) may 
be determined by identifying the valid VPF product features 
contained on each. Feature input from hardcopy source may be 
accomplished using any of a variety of methods including: manual 
digitization, keyboard input, scanning, heads-up digitizing, 
vectorizing raster (scanned) data, and automatic feature recognition. 
Factors influencing the selection of methods include: the capabilities 
of the collection hardware/software, the distribution of VPF features 
on the source materials, source availability, and convenience for the 
production operator. 

In producing VMapl, there were many instances where the 
outline of a feature would appear on one separate and the fill of that 
same feature would appear on another separate: cased roads, lakes, 
double line streams, and city tints to name a few. In most cases, if 
the feature outlines appeared on a separate with many other 
features, the fill separate need not be scanned. For cased roads, by 
scanning only the feature outline, the roads then could be heads-up 
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digitized through the casing. Because the software used allowed for 
area features to be placed by identifying faces, the bounding lines of 
the area feature were sufficient to place area features such as lakes 
or double-line streams. This same method of area feature collection 
worked well for features whose limits were bound by the edges of 
other features (eg. a sand feature bounded by the edges of drainage 
features). In the case of city tints, portions of the outlines may 
appear on one separate, with the fill on another. In this instance, it 
was easier to delete the city outline fragments and scan the separate 
containing the area fill. Because of variation, however, it became 
quickly evident that each case must be reviewed individually. 

Another issue to approach in advance is that of ancillary 
source. It must be decided what ancillary source is appropriate. 

Once deemed acceptable, the datum to which the ancillary source is 
referenced must be identified. This will determine the appropriate 
step during the data collection process (before or after datum 
transformation) to add the features. Also, guidelines for resolving 
likely conflicts between sources must be generated. The usage policy 
for primary and ancillary source should be documented both for the 
production operator (See "Extraction Guideline" below) and for the 
user (in metadata tables). 

In order to consistently address this variety of issues at 
production start up, a planning group was formed to help streamline 
VMapl production. This group examines the source materials for 
each entire library produced by DMA Aerospace Center to determine 
which materials and data input methods to use and to clarify 
ambiguous features found on the JOG source. The planning group 
also creates a checklist identifying on which piece of source specific 
VPF features could be found. In addition, the planning group 
prepares the separates to be scanned in ways that optimize 
automatic feature recognition and reduce editing time. For example, 
gaps may be closed on contour separates where the contour labels 
had been. 

Having a planning group identify and resolve these issues 
upfront is highly beneficial. It should be noted, however, that 
possessing an understanding of the source, the VPF product, and the 
collection software functionality is fundamental in making good 
planning decisions. 
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Simple Versus Compound Features 

VMapl has been defined only to allow for simple features. In 
other words, when features within the same coverage intersect lines 
or cross areas, a node is dropped and the line or area feature is split. 
Consider, for example, a dam with a single line stream on one side 
and a reservoir on the other side (see Figure-2). All three features 
are in the Hydrography Coverage, therefore the dam is intersected 
three times and is split into four segments. Because VMapl allows 
for only simple features, each one of those segments becomes a 
separate dam. Whereas a simple feature relates to only one 
primitive, a compound feature relates to more than one primitive of 
the same type. In this example, the entire dam made up of the four 
segments (primitives) would have been one compound feature. 



Although the decision to allow for compound (or even complex) 
features is made at the database design level, it is a decision which 
can have ramifications at the production level and in the final 
product. If a product is designed only with simple features, this 
limitation should be recognized and adhered to consistently. A 
problem may arise when the producer and/or user(s) later realize 
the desirability of the functionality allowed by compound features. 

At this point the producer has three choices: (1) redesign the 
product, (2) put the burden on the user, or (3) come up with a 
"workaround" and document it. 

This situation arose in VMapl production for the following 
features: runways, bridges, dams, tunnels, and piers. Each of these 
features has a length attribute present in the feature table. Ideally, 
if a length attribute exists, the graphic length of the feature will 
equal the value of its length attribute. Figure-3 shows two runways 
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crossing. Runway-1, whose total length is 1000 meters is split by 
Runway-2 into 400 meter and 600 meter segments. According to the 
rules of simple features, we now have four runways. Logically then, 
Runway-la, whose graphic length is 400 meters, would have a value 
of 400 meters in its length attribute. The burden to create the 
compound features would rest on the user if that functionality were 
desired. However, because both the user and producer realized that 
some compound feature functionality was needed, this was not the 
option chosen in the case of VMapl. Instead, a workaround was 
devised in which the length attribute reflected the cumulative length 
instead of the simple feature, or segment, length. In this example, 
both Runway-la and Runway-lb would have length attributes of 
1000 meters. Although this type of attribution procedure is 
documented within the product, a naive user could logically, but 
incorrectly, deduce that the total length of Runway-1 is 2000 meters. 


Runway-1 


a = 400 m 


Runway-2 


1000 m 


b = 600 m 


Figure-3 


I 


Although a product may be designed based on simple features, 
it is at the production level where this idea is implemented. 
Attribution decisions such as these at the production level affect the 
data consistency and useability. Any departure from the design's 
intent must be carefully documented. 


Narrative Tables 

Many collection/attribution decisions must be made by the 
producer. Because these are collection/attribution methods that are 
not outlined in the product specifications, or deviate from the 
design's intent as in the previous example, they must be documented 
carefully. VPF provides a means to do so through the use of 
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narrative tables. These optional tables may be associated with any 
VPF table or VPF table column and provide miscellaneous comments 
of information pertinent to the associated table or column. Narrative 
tables are located at the same physical level of the table they 
describe and are referenced in the header of the table. Where in the 
header the narrative table is referenced depends on the entity being 
described. Within a feature table a narrative table may be 
associated with the feature class, an individual feature, or even a 
particular attribute. 

Producing VMapl has required the use of many narrative 
tables, several of which outline rules followed in collecting coincident 
features. Under the Early Data Capture guidance, for features 
associated with roads and railroads (eg. bridges, dams, tunnels, 
embankments, snowsheds, and rocksheds), the general rule is: those 
features with a Transportation Use Category (TUC) attribute will not 
be coincident with roads or railroads. The TUC attribute indicates 
whether a feature is associated with a road, a railroad, both, or 
neither. Those features without a TUC attribute (snowsheds, 
rocksheds, and embankments) will be coincident with roads and 
railroads. Narrative tables describe collection methods for these 
individual features. 

VPF structure has two primitive types for point features: 
entity nodes, which are isolated points that may not be geometrically 
coincident with any edge in the same coverage, and connected nodes, 
which are points that must be coincident with an edge in the same 
coverage. Because of this VPF design characteristic, point features 
which have occurences of both types should be defined as two 
feature classes. Because this was not done for VMapl point features, 
either the positional accuracy of the feature or the continuity of the 
line network on which the point fell had to be compromised. 

Examples of problem features in VMapl are springs in linear 
drainage features, pumping stations connected to pipelines, and 
airports with linear runways. DMA decided that, for these examples, 
the linear network was more important than the positional accuracy 
of the point feature. As in the simple/compound feature situation 
discussed in the previous section, decisions made at the database 
design level can have repercussions in the final product. Narrative 
tables for these instances must be created to make the user aware of 
such collection methods. 

Narrative tables are also created which reference particular 
attributes for features. For example, trees on JOGs are depicted 
either as woods or scattered trees. Trees have a Density 
Measurement (DMT) attribute which, when taken from cartographic 
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source, cannot be determined. Because a distinction is made on JOGs 
between woods and scattered trees, a decision was made to assign in 
VMapl the average JOG density requirement for each. As a result, 
the DMT equals 30 percent for scattered trees and 80 percent for 
woods. The reference for the narrative table describing this 
attribution rule would be found in the column description for the 
DMT attribute in the header of the TREESA.AFT feature table. 

Some collection and attribution decisions which must be made 
are due to the fact that hardcopy cartographic source is being used, 
as in the example above. Situations concerning coincident features, 
however, would be encountered regardless of source. In both cases, 
narrative tables provide a means for the producer to describe 
collection and attribution methods employed. 


Extraction Guidelines 

Because of the many collection and attribution rules that must 
be decided outside the realm of a VPF product's specification, the 
development of an extraction guideline for the production operator is 
critical. In the previous section the importance of documentation for 
the user was stressed. It is equally important that the production 
operators have this information as well. 

The extraction guideline may be created in a variety of forms. 
While no particular format is required, continuity between the 
extraction guideline and the product specification is preferred. Two 
different formats were developed for the VMapl Extraction 
Guideline before one was chosen. Figures-4A and 4B depict the 
guidance for springs under the two formats. Format-A maintained 
the basic feature table structure (minus the header information) 
from the product specification and added general notes for the 
features below each table. Format-B addressed each feature 
individually, showing only those attributes applicable to each 
feature. In addition, Format-B tied each VMapl feature to a symbol 
number from the JOG specification and defined the attribution 
combination for each. Format-B was eventually chosen by DMA as 
the official format for the VMapl Extraction Guideline. 

It has been suggested that the information in the extraction 
guideline be included as part of the VPF product specification itself. 
This, however, is not advisable since the extraction guideline is 
source specific. The VPF product may not always be compiled using 
the same primary source. For that matter, it may not even be 
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Fiaure-4A Format-A for VMap1 Extraction Guideline 


TABLE 113 Well Spring Point Feature Table 


Thematic Layer 
Coverage Name; 

Feature Table Description: 
Table Name; 

DQ Layer Number. 


Hydrography 

HYDRO 

Well Spring Point Feature Table 

WELLSPRP.PFT 

3 




FACS 

FACC 


Ap^iHrable 



Value 

Value 

Value Meanina 

ID 

Row Identifier 

Sequential beginning with 1 



F_CODE 

FACS Feature Code 

P1AD50 

(AAOSO) 

Well 




P2H170 

{BH170} 

Spring / Water-Hole 




P2I010 

{BI010} 

Cistern 


EXS 

Existence Category 

-32767 


Null 

P2H170 



0 


Unknown 

P1A050, P2I010 



3 


Reported 

P1AD50 



6 


Abandoned 

{Abandoned / Disused) 

P1A050 



28 


Operational 

P1A050 



31 


Isolated 

P2I010 



42 

{61} 

Not Isolated 

P2I010 

HYC 

Hydrographic Category 
{Hydrological Category) 

-32767 


Null 

P2I010 



0 


Unknown 

P1A050, P2H170 



3 


Dry 

P1A050, P2H170 



6 


Non-Perennial / 
Intermittent / 

Ructuating 

P1A050, P2H170 



8 


Perennial / 

Permanent 

P1A050, P2H170 

NAM 

Name 

Variable length 

text=0-length 

Null 

P2H170, P2I010 




Character text string 

P1A050 




■UNK” 


(no entry 

present for feature) 

P1A050 

PRO 

Product Category 

•32767 


Null 

P2H170, P2I010 



0 


Unknown 

P1AD50 



27 

(116) 

Water 

P1A050 

see 

Spring/Well Characteristic Category 



R2I010 



-32767 


Null 



0 


Unknown 

P1A050, P2H170 



1 


Alkaline 

P1A050, P2H170 



4 


Mineral 

P1A050, P2H170 



9 


Freshwater / 

Potable 

P1A050, P2H170 

WFT 

Well Feature Type 

-32767 


Null 

P2H170, P2I010 



0 


Unknown 

P1AD50 



2 


Walled-in Spring 

P1A050 



3 


Artesian Well 

P1A050 



4 


Fountain 

P1A050 



5 


Dug or Drilled 

Well 

P1A050 


General Notes 

1: Hot springs and geysers may appear on a drainage separate symbolized as wells. They shall be collected as Geothemial 
features (P4B115). 

2: Regardless of symbolization of a cistern (tank or well), if they are labeled as a cistern they will be collected as such. 

3: If wells or spring fell on a linear drainage feature, the point feature shall be offset slightly to maintain the connectivity of the 
drainage network. If a well is defined as Brackish, &lt. Saline or Bitter Salt, use the Spring/Well Characteristic Category value 
Alkaline (SCC=1). 
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compiled using cartographic source. A VPF product specification 
should, therefore, be independent of guidance issued regarding 
source materials. The only items from the extraction guideline which 

might logically be included in the product specification would be 
those unrelated to source (coincident feature rules, for example). 

The extraction guideline should pull together the additional 
information needed by the production operator about the primary 
source, any ancillary source(s), and collection/attribution decisions 
not addressed in the product specification. It may also be helpful to 
include, for in-house versions, the relationship of these rules to the 
collection software being used. The development of a thorough and 
well organized extraction guideline is a major step towards assuring 
uniform collection and overall product integrity. 


Conclusions 

Keeping the previously discussed issues in mind, one last major 
consideration is that the same VPF product may be produced by 
more than one organization. Co-producers, contractors, or different 
components within the same agency may be involved. In this 
situation, coordination is essential. In the case of VMapl production, 
not only were two DMA components involved, but co-producers and 
contractors were involved as well. Due to many organizations using a 
variety of collection methods/software, it is imperative for product 
integrity that all involved have the same understanding of the final 
product, as was the case for the VMapl product. 

As mentioned in the previous section, a major step toward this 
goal is taken in the development of a common extraction guideline. 
Because the extraction guideline should include guidance on primary 
and ancillary sources, arbitrary collection/attribution decisions, and 
possibly how these relate to the collection software functionality, it is 
critical that the personnel making these decisions and compiling the 
guideline have a good understanding of the product and these issues. 
VPF product specifications do not cover many pertinent collection 
and attribution concerns, several of which are introduced through 
the use of cartographic source. While not always possible, it is 
strongly suggested that these issues be resolved prior to full-scale 
production to help to ensure quality and continuity. Also, the 
frustration factor runs high for personnel whose guidance, and even 
product specification, is in constant development and change. 
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Having a spatial product in the Vector Product Format will 
allow users a much wider range of analytical capabilities due to the 
ability for direct use within Geographic Information Systems. The 
accuracy of analysis performed on data in this format will heavily 
depend not only on the user's understanding of the product but also 
on the quality and consistency of the data itself. Resolving 
production issues before data collection begins will aid in assuring 
these characteristics for VPF product databases. 
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